Security policies and user roles
This chapter covers considerations administrators should make when selecting and setting a security policy for the ProtectToolkit-C environment. Many factors can affect operational security, and the various security features provided may affect ProtectToolkit-C performance and security during runtime operations.
Security policies overview
Security policies are sets of security settings that control how ProtectToolkit-C is allowed to function. For example, security policies can control the following:
-
Whether PINs can be passed across the host interface in an unencrypted form.
-
Whether a soft tamper (erase all internal secure memory) should occur as part of a firmware upgrade.
Organizations can create unique security policies to satisfy their own needs or adopt policies defined by standards bodies or other organizations.
Available security policies
A number of security settings offered as a part of ProtectToolkit-C implement typical security policies that meet certain standards or satisfy application integration requirements. These or any other custom security policy can be activated. The available options are fully described in Typical security policies. When implementing a security policy, the following should be considered:
-
If you are implementing a security policy to satisfy application integration requirements, other information may be available. Refer to the documentation for your specific application.
-
Compliance with the PKCS#11 standard will vary from policy to policy. Generally, stricter compliance results in lowered security. Refer to PKCS#11 compliance and security for further information.
-
Some security policy settings have effects that are specific to different user roles. Refer to User roles.
Implementing security policies
ProtectToolkit-C security policies are implemented by setting or clearing security flags to switch different functions on or off. Some policies are implemented by setting a single security flag while some policies are implemented by setting multiple flags. For more information about security flags, refer to Security Flags.
Note
After initial HSM installation or following a tamper event, the Default Mode security policy becomes active. While this policy ensures a high level of security, Thales recommends reading all of the information referenced above and setting a policy that meets the needs of your organization's ProtectServer 3 HSM deployment.
PKCS#11 compliance and security
ProtectToolkit-C can be configured for strict compliance with the PKCS#11 standard by using the security policy PKCS#11 Compatibility Mode. If a greater level of security is required, an alternate standard or custom security policy can be adopted. These and all other typical security policies are discussed in Typical Security Policies.
By default (after initial HSM installation or following a tamper event) the SafeNet Default Mode security policy is applied. This mode offers a greater level of security than PKCS#11 Compatibility Mode, while offering more PKCS#11 functions than other possible security policies.
For more about how SafeNet Default Mode differs from PKCS#11 Compatibility Mode, and the related security issues, refer to PKCS#11 Compatibility Mode.
